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Remarks 



Reconsideration of the application as amended herein is respectfully requested. Claims 
1-4 are pending in this application. Claim 1 has been amended. No claims have been added or 



The Office Action has rejected claims 1-4 under 35 U.S.C. § 103(a) as being 
unpatentable over Beausoleil et al., U.S. Patent No. 5,551,013 (hereinafter "Beausoleil") in view 
of Austin et al., U.S. Patent No. 4,885,684 (hereinafter "Austin") and further in view of Baker et 
al., U.S. Patent No. 5,701,502 (hereinafter "Baker"). AppHcants respectfully traverse this 
rejection. 

"To establish a prima facie case of obviousness, three basic criteria must be met. First, 
there must be some suggestion or motivation, either in the references themselves or in the 
knowledge generally available to one of ordinary skill in the art, to modify the reference or to 
combine reference teachings. Second, there must be a reasonable expectation of success. 
Finally, the prior art reference (or references when combined) must teach or suggest all the claim 
limitations." MPEP 2143. As explained below, neither Beaxisoleil, Austin nor Baker teach or 
suggest all of limitations of Claim 1. Furthermore, there is no suggestion or motivation combine 
these references. 

The Cited References Do Not Teach Or Suggest All Of The Claim Limitations 

The 1/03/05 Office Action states: 



The term 'blocking code' is not specific enough, hence has been construed 
as a form of artificial information that upon being decoded dictates some 
action such as to disable or prohibit access of part or all of resources, e.g., 
memory for read or write; and this is met by the MOP bit going one way 
or the other as cited. The claim does not describe in more precise terms 
how the so-called blocking code would clearly distinguish over what has 
been interpreted by [the] Examiner and used in the rejection: a bit whose 
status dictates that some part of memory cannot be accessed reads on 
access disabling or blocking code, e.g., if a part of memory location is 
prohibit for access (see col. 6, lines 52-59), what transfers there are 
between that part of memory and a plurality of processors being involved 
would be disabled, if not blocked. 



cancelled. 



Claim Rejections - 35 U,S.C> S103 
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See 1/3/05 Office Action at 8. In short, the Office Action has broadly interpreted the term 
"blocking code" to mean "a bit whose status dictates that some part of memory cannot be 
accessed." Id 

Claim 1 has been amended to further define the term "blocking code". Specifically, 
Applicant has amended claim 1 to clarify that the "blocking code blocks data transfers between 
said plurahty of module processors and said module main memory during the emulation step that 
includes the blocking code thereby allowing data to be transferred between said work station and 
said module main memory during the in progress emulation." This amendment makes clear that 
the "blocking code" is distinguishable firom "a bit whose status dictates that some part of 
memory cannot be accessed" as the amended claim states that the blocking code allows the 
module main memory to be accessed by the work station during an emulation. It also clearly 
distinguishes the claims from the MOP bit of Beausoleil. 

The amended claims are distinguishable fi-om Beausoleil for at least the following 
reasons. First, the MOP bit does not "block[] data transfers between said plurality of module 
processors and said module main memory'' In fact, the MOP bit does not control access to a 
"module main memory" in any way. The MOP bit simply controls whether a module processor 
will emulate a logic function or a memory function. See Beausoleil, Col. 6, 11. 14-27. When the 
MOP bit signals a memory operation, the right control word of the module processor functions as 
a memory that is addressed by a combination of data firom the left control word and the memory 
address register. See Beausoleil, Col. 6, 11. 14-27. Therefore, the MOP bit in Beausoleil only 
affects operation of the module processor and in no way "block[s] data transfers between said 
plurality of module processors and said module main memory'' 

Second, the MOP bit does not "allow data to be transferred between said work station and 
said module main memory during the in progress emulation." As mentioned above, the MOP bit 
simply controls whether a module processor will emulate a logic function or a memory function. 
See Beausoleil, Col. 6, II. 14-27. The MOP bit is not intended to allow for data transfer between 
a work station and a module main memory, and indeed the MOP bit does not allow for data 
transfer between a work station and a module main memory. 
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In sum, there is no teaching or suggestion in Beausoleil that the MOP bit or any other 
information present in a control word "blocks data transfers between said plurality of module 
processors and said module main memory during the emulation step that includes the blocking 
code thereby allowing data to be transferred between said work station and said module main 
memory during the in progress emulation." 

Additionally, neither Austin nor Baker teach or suggest a "blocking code" that "blocks 
data transfers between said plurality of module processors and said module main memory during 
the emulation step that includes the blocking code thereby allowing data to be transferred 
between said work station and said module main memory during the in progress emulation." 
The Office Action appears to concede this since these references are relied upon to meet other 
claim limitations. See 1/3/05 Office Action at 8-9. 



Like the present invention, Beausoleil relates to the emulation of integrated circuit 
designs. Austin and Baker, however, relate to completely different and unrelated technologies. 
Austin relates to a distributed data processing network, which has nothing to do with the 
emulation of integrated circuit designs. See, e.g.. Cols. 1-3. Similarly, Baker relates fault- 
tolerant mainfirame computer systems, which has nothing to do with the emulation of integrated 
circuit designs. See, e,g,. Col. 7, lines 33-38 ("Accordingly, it is intended that the present 
improvement will provide a fault tolerant environment and architecture for a normally non-fault- 
tolerant processing system and operating system without major rewrite of the operating system. 
In the preferred embodiment a model of IBM System/88 is coupled to a model of an IBM 
S/370."). 

There is simply no suggestion or motivation in any of these references to combine the 
references with one another. See MPEP 2143. Furthermore, one of ordinary skill in the art 
would not look to combine Austin or Baker with Beausoleil since each reference relates to 
unrelated areas of technology. 



There Is No Motivation Or Sugeestion To Combine The References 
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Dependent Claims 2-4 

The foregoing arguments apply to Claims 2-4, as they all are dependent on claim 1 . Therefore, 
Applicants respectfully submit that claims 2-4 are allowable as well. 



For the foregoing reasons, the Office Action has failed to establish a prima facie case of 
obviousness under 35 U.S.C. § 103. See MPEP 2143. Therefore, Applicants respectfully submit 
that this application is in condition for allowance, which is respectfully requested. Should the 
Examiner have any questions or comments on the application, the Examiner should feel free to 
contact the undersigned via telephone. 

The Commissioner is authorized to charge any fee which may be required in connection 
with this Amendment to deposit account No. 15-0665. 



Orrick, Herrington & Sutcliffe LLP 
4 Park Plaza, Suite 1600 
Irvine, CA 92614-2558 
Tel 650-614-7622 
Fax: 949-567-6710 



Conclusion 



Respectfully submitted, 

ORRICK, HERRINGTON & SUTCLIFFE LLP 



Dated: April 4, 2005 




Todd M. Briggs 
Reg. No. 44,040 
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